home *** CD-ROM | disk | FTP | other *** search
/ Cream of the Crop 1 / Cream of the Crop 1.iso / PROGRAM / TP061492.ARJ / 06-14-92.TPC
Text File  |  1992-06-14  |  41KB  |  1,285 lines
  1.  
  2. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  3.  
  4. Conference 4
  5. Date       01-01-00 00:00:00
  6. From       
  7. To         
  8. Subject    
  9.  
  10.  
  11. --- WM v2.01/92-0100
  12.  * Origin: A.C.E. of Spades (615)383-4381 The B.A.N. board (1:116/33)
  13.  * Tossed by SFToss v1.00b on 92/04/09  12:01:00
  14.  
  15. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  16.  
  17. Conference 4
  18. Date       06-07-92 01:04:18
  19. From       Trevor Carlsen
  20. To         Dj Murdoch
  21. Subject    Re: Tp 6 Exe Slow?
  22.  
  23.  
  24.  
  25.  DM> This takes 25 seconds to execute, on a 486-33 under Desqview as the 
  26.  DM> only active window.
  27.  
  28. This was what I considered a good opportunity to (very roughly) compare the
  29. overhead of DV.  On my similar machine the above took 6.919 seconds.
  30.  
  31. It would seem that DV imposes a significant performance penalty.
  32.  
  33. TeeCee
  34.  
  35. --- TC-ED   v2.01  
  36.  * Origin: The Pilbara's Pascal Centre (+61 91 732930) (3:690/644)
  37.  * Tossed by SFToss v1.00b on 92/06/07  13:19:56
  38.  
  39. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  40.  
  41. Conference 4
  42. Date       06-07-92 00:21:27
  43. From       Trevor Carlsen
  44. To         Tony Nugent
  45. Subject    Type-ing it Right!!
  46.  
  47.  
  48.  
  49.  TN> I have since got a reply (from my local Australian Pascal echo) 
  50.  TN> that nails the problem, and it was a subtle error in using SET 
  51.  TN> typing. 
  52.  
  53.  TN> What should be done in this case is to the following: 
  54.  
  55.  TN> type 
  56.  TN>   CharDigit = '0'..'9'; 
  57.  TN>   Digits = SET OF CharDigit; 
  58.  TN>   Postcode  : array[1..4] of Digits; 
  59.  TN>   { Postcode is a SET OF CharDigits!!! } 
  60.  
  61.  TN> after which the appropriate error code is generated. 
  62.  
  63.  TN> Very subtle difference, eh?  I thought I had sets understood, but 
  64.  TN> there are finer points to everything we learn! 
  65.  
  66.  TN> Of course, loading any data into this variable will, in "real 
  67.  TN> life", need to be tested as belong to type Digits before it is 
  68.  TN> put there. 
  69.  
  70. I do not recall seeing that reply locally and do not agree with it.  Doing
  71. it that way will prevent Postcode being displayed and will double its size
  72. to 8 bytes.  Hardly what you would want.
  73.  
  74. I would forget about the typing and do your own range-check on the characters.
  75.  
  76.  
  77. TeeCee
  78.  
  79. --- TC-ED   v2.01  
  80.  * Origin: The Pilbara's Pascal Centre (+61 91 732930) (3:690/644)
  81.  * Tossed by SFToss v1.00b on 92/06/07  13:19:56
  82.  
  83. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  84.  
  85. Conference 4
  86. Date       06-07-92 00:56:25
  87. From       Trevor Carlsen
  88. To         BRIAN PAPE
  89. Subject    PC CLOCK BYTE            
  90.  
  91.  
  92.  
  93.  BP> On all of the previous posts about the PC clock byte at ($40:$6C)?,
  94.  BP> people have said that you can directly map that memory into a Longint
  95.  BP> variable.  But, it seems to me that since the turbo Longint type is
  96.  BP> mapped like this:
  97.  
  98.  BP> xxxx xxxx xxxx xxxx
  99.  BP>   1    2    3    4
  100.  
  101.  BP> but in DOS, the dword is stored like this:
  102.  
  103.  BP> xxxx xxxx xxxx xxxx
  104.  BP>   4    3    2    1
  105.  
  106.  BP> you have to swap the bytes around to get the right value!
  107.  
  108.  BP> I tried it by mapping a Longint, but it didn't work, so I swapped the
  109.  BP> bytes:
  110.  BP> clock := (swap(clock shr 16) + (swap(clock) shl 16)
  111.  
  112.  BP> and this works...  I would appreciate it if someone told me how they 
  113.  
  114.  BP> did it without swapping the bytes around...
  115.  
  116. There is no need to do any "swapping around". The 4 bytes at $40:$6c are a
  117. standard longint type. 
  118.  
  119. I do not understand what you mean by having to "swap the bytes around to get
  120. the right value".  A longint is constructed in the standard Intel architecture
  121. style of -
  122.  
  123.   LSB .. MSB.
  124.  
  125. So the following -
  126.  
  127. type
  128.   long = array[0..3] of byte;
  129. var
  130.   demo : longint;
  131.   demoA: long absolute demo;
  132.   x    : 0..3;
  133. begin
  134.   demo := 1;
  135.   for x := 0 to 3 do
  136.     write(demoA[x]:4);
  137. end.
  138.  
  139. will result in
  140.  
  141.    1   0   0   0
  142.  
  143. To roughly calculate the hour of the day -
  144.  
  145. var
  146.   hour : word absolute $40:$6e;
  147.  
  148. and the word at $40:$6c will return the minutes if divided by 1092.
  149.  
  150. TeeCee
  151.  
  152. --- TC-ED   v2.01  
  153.  * Origin: The Pilbara's Pascal Centre (+61 91 732930) (3:690/644)
  154.  * Tossed by SFToss v1.00b on 92/06/07  13:19:56
  155.  
  156. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  157.  
  158. Conference 4
  159. Date       06-07-92 09:09:18
  160. From       Dj Murdoch
  161. To         Geoffrey Anderson
  162. Subject    Re: inverse of a polynomial
  163.  
  164.   GA> y = 2x^0 + 3x^1 ...
  165.  GA> I want to find g(y), that is, solve for x in terms of y, 
  166.  GA> for any such polynomial.  
  167.  
  168. There isn't necessarily a unique solution - a polynomial of degree D (i.e.
  169.  terms up to and including x^D) could have as many as D solutions.  There
  170. are exact formulas for the solutions up to D=4, but they're really only practica
  171.  up to D=2, so you need an approximation technique.  
  172.  
  173. One is bisection:  just guess at a couple of x values which bracket y, then
  174. replace one end by the midpoint until you find something pretty close to g(y).
  175.  For odd D, the guess is easy, but it may not be so easy for even D. 
  176.  
  177. Take a look in Numerical Recipes [in Pascal], by Press et al, for a good discuss
  178. on and some code.
  179.  
  180. --- Msg V3.2
  181.  * Origin: Murdoch's_Point  - -   (1:221/177.40)
  182.  * Tossed by SFToss v1.00b on 92/06/08  12:11:05
  183.  
  184. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  185.  
  186. Conference 4
  187. Date       06-07-92 09:16:08
  188. From       Dj Murdoch
  189. To         Frank Mccormick
  190. Subject    Re: Rewriting Output
  191.  
  192.   FM> Hope to get some help here...
  193.  FM>  When you subvert direct video in TP 4/5/6 by assigning 
  194.  FM> Output to a null file and rewriting it, how do you get 
  195.  FM> back to a normal situation ?
  196.  FM> I have written an ANSI based door which does the 
  197.  FM> above...but then when the door returns to the BBS, the 
  198.  FM> windows no longer work because Output has been redirected.
  199.  
  200. Use AssignCRT.
  201.  
  202. --- Msg V3.2
  203.  * Origin: Murdoch's_Point  - -   (1:221/177.40)
  204.  * Tossed by SFToss v1.00b on 92/06/08  12:11:05
  205.  
  206. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  207.  
  208. Conference 4
  209. Date       06-08-92 01:59:24
  210. From       Trevor Carlsen
  211. To         David Vohwinkel
  212. Subject    Memory Management
  213.  
  214.  
  215.  
  216.  DV> Does anyone know of a way to make a Pascal program remove
  217.  DV> itself from memory so that you can call an external program
  218.  DV> that is bigger than 60k wich is the limit I think... I want
  219.  DV> to write a Pascal program that 'shells out' to a seperate
  220.  DV> program that is say 250k...
  221.  
  222. There is no 60K limit on the EXECing of a child process.  Check out your manual
  223. or help system on EXEC.
  224.  
  225. To swap ITSELF out of memory before an exec is another (very complex) matter.
  226.  To demonstrate the process would be beyond the scope of a message.  Suffice
  227. it to say that it is not strictly  possible.  Some part of the original program
  228. MUST remain present in RAM at all times.
  229.  
  230. TeeCee
  231.  
  232.  
  233.  
  234. --- TC-ED   v2.01  
  235.  * Origin: The Pilbara's Pascal Centre (+61 91 732930) (3:690/644)
  236.  * Tossed by SFToss v1.00b on 92/06/08  19:58:22
  237.  
  238. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  239.  
  240. Conference 4
  241. Date       06-08-92 02:05:04
  242. From       Trevor Carlsen
  243. To         Daniel Walton
  244. Subject    File Pointer size
  245.  
  246.  
  247.  
  248.  DW> I am writing a program that uses frequent access to the disk
  249.  DW> and for some reason Turbo Pascal 6 is assigning an integer
  250.  DW> value to the file pointer. Therefore when I have the
  251.  DW> Blockread size set to 1 byte I cannot read in more than 32K
  252.  DW> worth of data.  So how do I set the file pointer to a long
  253.  DW> integer?
  254.  
  255. Without you demonstrating what you are doing it is impossible to determine
  256. what is wrong.  The help system demo shows how to use BlockRead adequately.
  257.  
  258. TeeCee
  259.  
  260. --- TC-ED   v2.01  
  261.  * Origin: The Pilbara's Pascal Centre (+61 91 732930) (3:690/644)
  262.  * Tossed by SFToss v1.00b on 92/06/08  19:58:22
  263.  
  264. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  265.  
  266. Conference 4
  267. Date       06-08-92 08:03:23
  268. From       Dj Murdoch
  269. To         Trevor Carlsen
  270. Subject    Re: Tp 6 Exe Slow?
  271.  
  272.   TC> This was what I considered a good opportunity to (very 
  273.  TC> roughly) compare the overhead of DV.  On my similar 
  274.  TC> machine the above took 6.919 seconds.
  275.  
  276.  TC> It would seem that DV imposes a significant performance penalty.
  277.  
  278. It usually seems to be less than 70% overhead.  Perhaps I was wrong about
  279. that window being the only active one.  Hmmm....
  280.  
  281. --- Msg V3.2
  282.  * Origin: Murdoch's_Point  - -   (1:221/177.40)
  283.  * Tossed by SFToss v1.00b on 92/06/09  17:09:58
  284.  
  285. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  286.  
  287. Conference 4
  288. Date       06-08-92 08:16:26
  289. From       Dj Murdoch
  290. To         Trevor Carlsen
  291. Subject    Re: Tp 6 Exe Slow?
  292.  
  293.   DM> This takes 25 seconds to execute, on a 486-33 under Desqview as the 
  294.  DM> only active window.
  295.  
  296.  TC> This was what I considered a good opportunity to (very 
  297.  TC> roughly) compare the overhead of DV.  On my similar 
  298.  TC> machine the above took 6.919 seconds.
  299.  
  300.  TC> It would seem that DV imposes a significant performance penalty.
  301.  
  302. Just redid the tests.  On a barebones machine, or one with just QEMM loaded,
  303. I get about 16 or 17 seconds.  In a single Desqview window I get the same.
  304.  Running two Desqview windows, with one just sitting at the prompt, I get
  305. 25 seconds.  (That must have been what I had the first time.)  Running the
  306. same program simultaneously in the two windows, I get 33 seconds.
  307.  
  308. So, it looks as though the Desqview overhead is pretty minimal - better than
  309. I thought - provided you don't leave windows sitting idle.
  310.  
  311. I don't know why you got 7 seconds though - what sort of machine have you
  312. got?  Mine is a DTK, with supposedly a 256K cache.  Norton's old SYSINFO gives
  313. it a 51.  
  314.  
  315. --- Msg V3.2
  316.  * Origin: Murdoch's_Point  - -   (1:221/177.40)
  317.  * Tossed by SFToss v1.00b on 92/06/09  17:09:58
  318.  
  319. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  320.  
  321. Conference 4
  322. Date       06-08-92 08:21:14
  323. From       Dj Murdoch
  324. To         Daniel Walton
  325. Subject    Re: File Pointer size
  326.  
  327.   DW>        I am writing a program that uses frequent access to 
  328.  DW> the disk and for
  329.  DW> some reason Turbo Pascal 6 is assigning an integer value 
  330.  DW> to the file pointer.
  331.  DW> Therefore when I have the Blockread size set to 1 byte I 
  332.  DW> cannot read in more
  333.  DW> than 32K worth of data.  So how do I set the file pointer 
  334.  DW> to a long integer?
  335.  
  336. You're probably not setting the block size when you use BlockRead.  That's
  337. one reason not to use it - it's a very easy mistake to make.  (You need to
  338. say Reset(filevar,1).)  Use a TBufStream or a TDOSStream instead.  
  339.  
  340. --- Msg V3.2
  341.  * Origin: Murdoch's_Point  - -   (1:221/177.40)
  342.  * Tossed by SFToss v1.00b on 92/06/09  17:09:58
  343.  
  344. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  345.  
  346. Conference 4
  347. Date       06-07-92 21:32:16
  348. From       Mark Ouellet
  349. To         Jud Mccranie
  350. Subject    Re: Impact Of .Tpu Size O
  351.  
  352.  
  353.     On 03 Jun 92, you, Jud Mccranie, of 1:3645/10.0 wrote...
  354.  
  355.  MO>>>>         Remember using CRT installs video routines which
  356.  MO>>>> handle screen writes, those same routines you showed people
  357.  MO>>>> how to bypass to write ANSI screens.
  358.  MO>>
  359.  JM>>> That wasn't me.
  360.  JM>>>
  361.  MO>>>>         So naturely, anything used must be kept by the
  362.  MO>>>> linker but try using other routines such as WRITE and
  363.  MO>>>> WRITELN and GOTOXY etc... you'll see they were discarded
  364.  MO>>>> when you first compiled without using them.
  365.  MO>>
  366.  MO>> Jud,
  367.  MO>>         Allow me to refresh your memory ;-)
  368.  
  369.  JM> No, you're still wrong.  I NEVER wrote the paragraph above.  Note that
  370.  JM> it is a quote of a quote.  Someone wrote to someone else, I quoted, and
  371.  JM> it was left in there.  You are assuming that the original was from me,
  372.  JM> someone replied.  But actually it was person A to person B, then I
  373.  JM> replied to that message, and quoted some of it, and that was in there.
  374.  JM> I did make a comment that "uses crt" adds to the exe file, even if you
  375.      ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  376.  JM> don't use anything from it, but I *never* said what you said I said.
  377.      ^^^^^^^^^^^^^^^^^^^^^^^^^^      ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  378. Jud,
  379.         That's funny because what I said you said was
  380. exactly that: "That you said the CRT adds to the size
  381. eventhough you don't use anything".
  382.  
  383.         And I was trying to explain to you, since from a
  384. previous message in which you said you didn't know WHY the
  385. crt unit added to the .exe size even if you used nothing.
  386.  
  387.         If you had just read the message and taken it for
  388. what it was, an explanation, instead of jumping on your
  389. paranoia wagon again, we wouldn't have to clutter this echo
  390. with these messages.
  391.  
  392.         If you have anything more to say on the subject, I
  393. will only reply to Netmail from now on.
  394.  
  395.         Best regards,
  396.         Mark Ouellet.
  397.  
  398.  
  399.  
  400. --- ME2
  401.  * Origin: Governements, Proof of Peter's principle (Fidonet 1:240/1.4)
  402.  * Tossed by SFToss v1.00b on 92/06/09  17:10:01
  403.  
  404. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  405.  
  406. Conference 4
  407. Date       06-07-92 21:44:13
  408. From       Mark Ouellet
  409. To         Sean Ocker
  410. Subject    Re: SBlaster...
  411.  
  412.  
  413.     On 02 Jun 92, you, Sean Ocker, of 1:117/369.0 wrote...
  414.  
  415.  SO> Call 1:117/349.  It is a two-line BBS with 3.8+ gigs.  It has 4 CD ROMS
  416.  SO> and one is the Magnum Sights and Sounds. FREQ's are not allowed off it
  417.  SO> (CD's are too slow) but they have a 14.4 on one of the lines.
  418.  SO> 
  419.  SO> My address is 1:117/369.  Sorry about that.
  420.  
  421. Sean,
  422.         Thanks, I might take a look but I prefer Freq'ing as
  423. logging on as a human caller often makes the difference
  424. between spending a few bucks for a file and a large LD bill.
  425.  
  426.         Best regards,
  427.         Mark Ouellet.
  428.  
  429.  
  430.  
  431. --- ME2
  432.  * Origin: Governements, Proof of Peter's principle (Fidonet 1:240/1.4)
  433.  * Tossed by SFToss v1.00b on 92/06/09  17:10:01
  434.  
  435. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  436.  
  437. Conference 4
  438. Date       06-07-92 21:46:34
  439. From       Mark Ouellet
  440. To         David Masaki
  441. Subject    Re: Compressing Binary Sorted Trees
  442.  
  443.  
  444.     On 02 Jun 92, you, David Masaki, of 1:345/27.0 wrote...
  445.  
  446.  DM> You're right in that what I described earlier would produce a binary 
  447.  
  448.  DM> sorted tree with all it's nodes on one side and produce the exact 
  449.  DM> opposite effect of what I wanted.  What I want is for the tree after a 
  450.  
  451.  DM> bunch of insertions which would make it less efficient to be compressed 
  452.  
  453.  DM> (made into it's most efficient form).  How would that be done? 
  454.  
  455. Well David,
  456.         as I stated in the original message, AVL or Balanced
  457. Binary Trees do balance the tree on each insertion so as to
  458. insure a minimum search path for any node.
  459.  
  460.         I think many B+Tree libraries are available, Borland
  461. used to make one ie: Turbo Database Toolbox, which is not
  462. sold anymore I think. Last version was for TP 4.0 I think
  463. but might be compatible with newer versions of TP.
  464.  
  465.         Turbo Power also produces a database library which
  466. includes B+Tree indexes I think.
  467.  
  468.         Other than that you would have to find a good book
  469. on AVL or B+Trees, and if you do let me know as I have been
  470. searching for a good one too.
  471.  
  472.         Best regards,
  473.         Mark Ouellet.
  474.  
  475.  
  476.  
  477. --- ME2
  478.  * Origin: Governements, Proof of Peter's principle (Fidonet 1:240/1.4)
  479.  * Tossed by SFToss v1.00b on 92/06/09  17:10:01
  480.  
  481. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  482.  
  483. Conference 4
  484. Date       06-07-92 21:51:17
  485. From       Mark Ouellet
  486. To         Kevin Higgins
  487. Subject    Re: Looking for SHAZAM (TV App. code gen
  488.  
  489.  
  490.     On 03 Jun 92, you, Kevin Higgins, of 1:128/74.0 wrote...
  491.  
  492.  KH> Ah, another person who spent time uploading there, to build a decent 
  493.  
  494.  KH> file ratio, then got cut off when Turbo City decided to only grant 
  495.  KH> access to those who would cough up money, eh?
  496.  
  497. Kevin,
  498.         Wrong assertion, I simply found the file there after
  499. some one recomended their library but since I couldn't freq
  500. form it I was simply trying to find another source.
  501.  
  502.         Best regards,
  503.         Mark Ouellet.
  504.  
  505.  
  506.  
  507. --- ME2
  508.  * Origin: Governements, Proof of Peter's principle (Fidonet 1:240/1.4)
  509.  * Tossed by SFToss v1.00b on 92/06/09  17:10:02
  510.  
  511. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  512.  
  513. Conference 4
  514. Date       06-07-92 21:54:04
  515. From       Mark Ouellet
  516. To         David Rye
  517. Subject    Re: Pascal source
  518.  
  519.  
  520.     On 26 May 92, you, David Rye, of 1:240/1.4 wrote...
  521.  
  522.  DR> If it weren't for Turbo City I never would have been able to keep up 
  523.  
  524.  DR> to date of various techniques and tips that have kept me employed as a 
  525.  
  526.  DR> programmer.
  527.  
  528.         Yes they do have some very nice stuff. The zone 2
  529. Turbo City is not bad either. Lots of SB/Adlib stuff along
  530. with TP stuff.
  531.  
  532.  DR> I think Pam requires a password for freqs, you might want to drop 
  533.  DR> her some netmail and ask about that though.
  534.  
  535.         Well it seems from the what I received with FILES
  536. that you must be a registered member to even Freq.
  537.  
  538.  
  539.         Best regards,
  540.         Mark Ouellet.
  541.  
  542.  
  543.  
  544. --- ME2
  545.  * Origin: Governements, Proof of Peter's principle (Fidonet 1:240/1.4)
  546.  * Tossed by SFToss v1.00b on 92/06/09  17:10:02
  547.  
  548. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  549.  
  550. Conference 4
  551. Date       06-07-92 22:12:26
  552. From       Mark Ouellet
  553. To         Ryan Brown
  554. Subject    Re: e-mail
  555.  
  556.  
  557.     On 01 Jun 92, you, Ryan Brown, of 1:203/674.0 wrote...
  558.  
  559.  RB> What is pegasus?
  560.  
  561.         It's an e-mail system for Novell Networks. It also
  562. allows file attaches between stations.
  563.  
  564. And it's FREEware.
  565.  
  566.         Best regards,
  567.         Mark Ouellet.
  568.  
  569.  
  570.  
  571. --- ME2
  572.  * Origin: Governements, Proof of Peter's principle (Fidonet 1:240/1.4)
  573.  * Tossed by SFToss v1.00b on 92/06/09  17:10:02
  574.  
  575. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  576.  
  577. Conference 4
  578. Date       06-09-92 02:34:54
  579. From       Trevor Carlsen
  580. To         Peter Beeftink
  581. Subject    Writing directly to disk sectors.
  582.  
  583.  
  584.  
  585.  PB>... How do I truncate to "the old length" though?
  586.  
  587. Look up truncate in the manual.
  588.  
  589. TeeCee
  590.  
  591. --- TC-ED   v2.01  
  592.  * Origin: The Pilbara's Pascal Centre (+61 91 732930) (3:690/644)
  593.  * Tossed by SFToss v1.00b on 92/06/09  19:32:44
  594.  
  595. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  596.  
  597. Conference 4
  598. Date       06-09-92 03:50:20
  599. From       Trevor Carlsen
  600. To         Peter Beeftink
  601. Subject    getftime()
  602.  
  603.  
  604.  
  605.  PB> As I found out the hard way, before you can successfully use
  606.  PB> getftime, you have to open (reset();) the file in question.
  607.  PB> Now, is it possible to read the time_of_creation of a
  608.  PB> directory(-file)????
  609.  
  610. Just use FindFirst/FindNext with the appropriate mask.  The creation time
  611. can be determined from the timestamp.  
  612.  
  613. TeeCee
  614.  
  615. --- TC-ED   v2.01  
  616.  * Origin: The Pilbara's Pascal Centre (+61 91 732930) (3:690/644)
  617.  * Tossed by SFToss v1.00b on 92/06/09  19:32:45
  618.  
  619. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  620.  
  621. Conference 4
  622. Date       06-09-92 03:00:48
  623. From       Trevor Carlsen
  624. To         Frank Mccormick
  625. Subject    Rewriting Output
  626.  
  627.  
  628.  
  629.  FM>  When you subvert direct video in TP 4/5/6 by assigning
  630.  FM> Output to a null file and rewriting it, how do you get back
  631.  FM> to a normal situation
  632.  
  633. This is covered in the manual... but not obviously!  AssignCRT is the procedure
  634. you are looking for.  So to return stdout to the normal crt setup -
  635.  
  636. assignCRT(output); rewrite(output);
  637.  
  638. (Chapter 15 - The CRT unit.  p 199)
  639.  
  640. TeeCee
  641.  
  642. --- TC-ED   v2.01  
  643.  * Origin: The Pilbara's Pascal Centre (+61 91 732930) (3:690/644)
  644.  * Tossed by SFToss v1.00b on 92/06/09  19:32:45
  645.  
  646. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  647.  
  648. Conference 4
  649. Date       06-09-92 03:53:08
  650. From       Trevor Carlsen
  651. To         Tony Nugent
  652. Subject    MCGA Tutorial #5
  653.  
  654.  
  655.  
  656.  TN> Hey, great stuff.  Should be more of this type of thing.
  657.  TN> However, I did not get all the code as it got cut out either
  658.  TN> in transit through the systems (I'm in Brisbane Aust), or by
  659.  TN> my offline reader...
  660.  TN> ... While appreciated by people such as myself (don't know
  661.  TN> about those that zap this stuff log distance around the
  662.  TN> world :-), your longer messages need to be cut shorter and
  663.  TN> posted as several smaller parts.  It does look like
  664.  TN> interesting code, but it's not complete for me :-(
  665.  
  666. The message will be complete on the system.  (It was complete here)  Perhaps
  667. you could get it by a direct message read rather than by your reader.
  668.  
  669. I have had several requests from echo users to enforce this echo's 150 line
  670. message limit. I don't intend taking a strong stance on that, as the full
  671. text of the messages are almost always available on the main board.  It is
  672. (or certainly should be) only the crippled readers that are doing the truncating
  673.   In fact, in the majority of cases the complete text is probably available
  674. in your own packet.
  675.  
  676. Even so, it would be considered "good form" if all those posting long messages
  677. would do everybody the courtesy of abiding by the echo rule of no messgaes
  678. over 150 lines.  For those whose readers truncate at 100 lines - tough.  Get
  679. a decent reader! :-)
  680.  
  681. TeeCee
  682.  
  683. --- TC-ED   v2.01  
  684.  * Origin: The Pilbara's Pascal Centre (+61 91 732930) (3:690/644)
  685.  * Tossed by SFToss v1.00b on 92/06/09  19:32:45
  686.  
  687. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  688.  
  689. Conference 4
  690. Date       06-09-92 03:57:52
  691. From       Trevor Carlsen
  692. To         Patrick Craig
  693. Subject    Lots of "thanks"
  694.  
  695.  
  696.  
  697.  PC>   Though the lingo is a bit over the top of my head, I do appreciate 
  698.  
  699.  PC> the information.  Thanks!
  700.  
  701. Patrick, I don't normally worry too much about "thank-you" type messages but
  702. this echo does have a rule on this (see excerpt below).  The reason I point
  703. this out to you is that there were ten such messages from you today!  Your
  704. sysop should have the complete text of the echo rules available.  They are
  705. posted monthly.
  706.  
  707.  8. No "thank-you" or "no content" or "rubbish" messages. Sysops spend a
  708.     great deal of time and money to enable the distribution of echoes
  709.     such as this. Please respect this and avoid messages such as "Thank
  710.     you. Just what I needed" or "I agree" etc. By observing this
  711.     etiquette you will be helping to ensure greater participation in the
  712.     future.
  713.  
  714. Thanks.  (No need to reply to this.)
  715.  
  716. Trevor Carlsen
  717. Moderator.
  718.  
  719. --- TC-ED   v2.01  
  720.  * Origin: The Pilbara's Pascal Centre (+61 91 732930) (3:690/644)
  721.  * Tossed by SFToss v1.00b on 92/06/09  19:32:45
  722.  
  723. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  724.  
  725. Conference 4
  726. Date       06-09-92 07:59:50
  727. From       Trevor Carlsen
  728. To         Greg Williams
  729. Subject    Memory Management
  730.  
  731.  
  732.  
  733.  TC> To swap ITSELF out of memory before an exec is another 
  734.  TC> (very complex) matter.  To demonstrate the process 
  735.  TC> would be beyond the scope of a message.  Suffice it to 
  736.  TC> say that it is not strictly  possible.  Some part of 
  737.  TC> the original program MUST remain present in RAM at all 
  738.  TC> times.
  739.  
  740.  GW> Hmm.... the only reason we tend to leave only the "reload" fragment of 
  741.  
  742.  GW> the program in memory (while swapping the rest out) is to do just that 
  743.  
  744.  GW> (reload, when the child process is finished).  However, would it not 
  745.  
  746.  GW> be possible to do something similar to what the UNIX fork()and exec() 
  747.  
  748.  GW> command combination does, and totally overwrite the parent process 
  749.  GW> with the new process?
  750.  
  751. If the process was being managed by the OS then there should not be great
  752. difficulty. When the process being swapped out is doing the swapping, I cannot
  753. see how there can be an alternative to retaining some of that process in RAM.
  754.  
  755. I have Turbo Power's "PopDos" loaded as my first TSR.  I can "pop" to DOS
  756. with 620K of free memory from any program if the TSR determines that it is
  757. safe to do so.  This means that an application that is running is swapped
  758. out in its entirety but the swapper is the TSR and NOT the application.
  759.  
  760. As a matter of interest, PopDos has been a Godsend for me during my program
  761. development work.  If I have a lockup, I just pop to dos, save the contents
  762. of my Ramdrives and then reboot.  Without it my ramdrive stuff may be lost.
  763.  
  764. TeeCee
  765.  
  766. --- TC-ED   v2.01  
  767.  * Origin: The Pilbara's Pascal Centre (+61 91 732930) (3:690/644)
  768.  * Tossed by SFToss v1.00b on 92/06/09  19:32:45
  769.  
  770. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  771.  
  772. Conference 4
  773. Date       06-09-92 09:04:32
  774. From       Trevor Carlsen
  775. To         Jud Mccranie
  776. Subject    Re: Tp 6 Exe Slow?
  777.  
  778.  
  779.  
  780.  JM> P.S.  I'm uploading it here, ANAGRTST.ZIP, 3K, simplified source code,
  781.  JM> sample data file.  TP 6.0 (with G+ even)  takes about 8% longer to
  782.  JM> execute than TP 5.5.
  783.  
  784. Mmmmm... Looks like your sysop expects a password.  After the Yoohoo/2U2 handsha
  785. e I was summarily dismissed.
  786.  
  787. TeeCee
  788.  
  789. --- TC-ED   v2.01  
  790.  * Origin: The Pilbara's Pascal Centre (+61 91 732930) (3:690/644)
  791.  * Tossed by SFToss v1.00b on 92/06/09  19:32:45
  792.  
  793. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  794.  
  795. Conference 4
  796. Date       06-09-92 09:07:57
  797. From       Trevor Carlsen
  798. To         Justin Henry
  799. Subject    Removing 32 Bytes from File
  800.  
  801.  
  802.  
  803.  JH>    How would I go about removing the first 32 bytes from an untyped
  804.  JH>    file? Read 1 byte 32 times, then read and write the rest? Would 
  805.  JH>    someone suggest an easier way? By the way, I am trying to remove
  806.  JH>    the 32-Byte Header from a Sound Blaster .VOC file. 
  807.  
  808. Declare the file as untyped with a record size of 1.  Seek to offset 32 and
  809. read however many bytes you want into an appropriately sized and declared
  810. buffer.
  811.  
  812. var
  813.   f        : file;
  814.   buffer   : array[1..32768] of byte;
  815.   result   : word;
  816.  
  817. begin
  818.   assign(f,filename);
  819.   reset(f,1);
  820.   seek(f,32);
  821.   BlockRead(f,buffer,sizeof(buffer),result);
  822.  
  823. TeeCee
  824.  
  825.  
  826. --- TC-ED   v2.01  
  827.  * Origin: The Pilbara's Pascal Centre (+61 91 732930) (3:690/644)
  828.  * Tossed by SFToss v1.00b on 92/06/09  19:32:45
  829.  
  830. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  831.  
  832. Conference 4
  833. Date       06-09-92 09:50:48
  834. From       Trevor Carlsen
  835. To         Rich Veraa
  836. Subject    Your problem
  837.  
  838.  
  839.  
  840. I cannot locate your exact problem but it appears to be an out-of-range error
  841. on the variable index.  Check that out carefully.
  842.  
  843. TeeCee
  844.  
  845. --- TC-ED   v2.01  
  846.  * Origin: The Pilbara's Pascal Centre (+61 91 732930) (3:690/644)
  847.  * Tossed by SFToss v1.00b on 92/06/09  19:32:45
  848.  
  849. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  850.  
  851. Conference 4
  852. Date       06-09-92 20:53:00
  853. From       Norbert Igl
  854. To         Peter Beeftink
  855. Subject    getftime()
  856.  
  857.  
  858.  
  859.  
  860.  > Hello All!
  861.  
  862.  > As I found out the hard way, before you can successfully use
  863.  > getftime, you have to open (reset();) the file in question.  Now, is
  864.  > it possible to read the time_of_creation of a directory(-file)????
  865.  
  866.    Shure i do....
  867. -------------------------8<---------------------------------
  868. uses dos;
  869. [...]
  870. function GetDirTime(Name:PathStr):longint;
  871. Var Sr : SearchRec;
  872. begin
  873.   findfirst(Name, DIRECTORY, Sr);
  874.   while ( DosError = 0 ) and ((Sr.Attr and DIRECTORY) <> 0)
  875.     do FindNext(Sr);
  876.   If DosError = 0
  877.     then GetDirTime := Sr.Time
  878.     else GetDirTime := -1;
  879. end;
  880. [...]
  881. Var Dt : DateTime;
  882.     L  : LongInt;
  883. begin
  884.   L:= GetDirTime('C:\WINDOWS');
  885.   if L <> -1 then
  886.   begin
  887.     UnpackTime(L, Dt);
  888.     with Dt do
  889.       writeln('C:\WINDOWS was created at ',Day,'.',month,'.',Year,' - '
  890.                                           ,Hour:2,':',Min:2,':',Sec:2 );
  891.    end else
  892.    writeln('C:\WINDOWS not found....');
  893. end.
  894. ------------------------->8---------------------------------
  895.    sorry for the typos, if any...
  896.    Bye from Germany, Norbert
  897.  
  898. --- FD 2.02/FastEcho
  899.  * Origin: STOP READING! You're leaving the MSG-sector (2:241/5300.3)
  900.  * Tossed by SFToss v1.00b on 92/06/10  07:40:08
  901.  
  902. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  903.  
  904. Conference 4
  905. Date       06-09-92 07:50:20
  906. From       Dj Murdoch
  907. To         Justin Henry
  908. Subject    Re: Removing 32 Bytes from File
  909.  
  910.   JH>    How would I go about removing the first 32 bytes from an untyped
  911.  JH>    file? Read 1 byte 32 times, then read and write the rest? Would 
  912.  JH>    someone suggest an easier way? By the way, I am trying to remove
  913.  JH>    the 32-Byte Header from a Sound Blaster .VOC file. 
  914.  
  915. If you're using TP 6.0, the easiest way is using streams:
  916.  
  917. uses
  918.   objects; var
  919.   infile, outfile : TDOSStream; begin
  920.   infile.init('inputfilename',stOpenRead);
  921.   infile.seek(32);     { remember byte 32 is the 33rd byte }
  922.   outfile.init('outputfilename',stCreate);
  923.   outfile.copyfrom(infile, infile.Getsize-32);
  924.   infile.done;
  925.   outfile.done; end.
  926.  
  927. The same thing can be done as you suggest, but it'll be much slower.  It can
  928. be done with about equal speed using BlockRead/BlockWrite, but won't be as
  929. simple:  you'll have to set up a buffer, and loop until you've copied the
  930. whole file.
  931.  
  932. --- Msg V3.2
  933.  * Origin: Murdoch's_Point  - -   (1:221/177.40)
  934.  * Tossed by SFToss v1.00b on 92/06/10  10:56:01
  935.  
  936. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  937.  
  938. Conference 4
  939. Date       06-09-92 07:55:03
  940. From       Dj Murdoch
  941. To         Jud Mccranie
  942. Subject    Re: Topics..
  943.  
  944.   JM> Sorry, I didn't realize that.  I thought that was the reason for the
  945.  JM> "lessons", to lessen (no pun intended) the traffic in elementry
  946.  JM> questions here.  As you may have noticed, however, I'm often quick to
  947.  JM> --- 
  948.  JM>  * Origin: Business Connection 1.2Gigs (912)247-6977 (1:3645/10)
  949.  
  950. A lot of your messages have had the last line (or more?) chopped off like
  951. this.  I've noticed that some mail editors mess up if the message you enter
  952. doesn't have a blank line at the end - perhaps you should check yours out.
  953.  
  954. --- Msg V3.2
  955.  * Origin: Murdoch's_Point  - -   (1:221/177.40)
  956.  * Tossed by SFToss v1.00b on 92/06/10  10:56:02
  957.  
  958. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  959.  
  960. Conference 4
  961. Date       06-11-92 09:10:27
  962. From       Trevor Carlsen
  963. To         Max Maischein
  964. Subject    File Pointer size
  965.  
  966.  
  967.  
  968.  >        I am writing a program that uses frequent access to the
  969.  > disk and for
  970.  > some reason Turbo Pascal 6 is assigning an integer value to the
  971.  > file pointer.
  972.  > Therefore when I have the Blockread size set to 1 byte I cannot
  973.  > read in more
  974.  > than 32K worth of data.  So how do I set the file pointer to a
  975.  > long integer?
  976.  
  977.  MM> This is the limit of DOS ;-)
  978.  
  979. No it is not...  the file pointer is a longint and bears no relationship to
  980. the number of bytes that can be read at a time.  The most that can be read
  981. is 64K not 32K.  Without seeing what is being done, we can only surmise. 
  982. Looks to me like an integer type is being used instead of a word type.
  983.  
  984. TeeCee
  985.  
  986.  
  987. --- TC-ED   v2.01  
  988.  * Origin: The Pilbara's Pascal Centre (+61 91 732930) (3:690/644)
  989.  * Tossed by SFToss v1.00b on 92/06/11  11:49:41
  990.  
  991. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  992.  
  993. Conference 4
  994. Date       06-11-92 09:13:34
  995. From       Trevor Carlsen
  996. To         John Black
  997. Subject    Getting the current directory string
  998.  
  999.  
  1000.  
  1001.  JB> ... I can't find a way to get what 
  1002.  JB> the current directory is...
  1003.  
  1004. Look up GetDir in the manual.
  1005.  
  1006. TeeCee
  1007.  
  1008. --- TC-ED   v2.01  
  1009.  * Origin: The Pilbara's Pascal Centre (+61 91 732930) (3:690/644)
  1010.  * Tossed by SFToss v1.00b on 92/06/11  11:49:41
  1011.  
  1012. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  1013.  
  1014. Conference 4
  1015. Date       06-11-92 09:15:16
  1016. From       Trevor Carlsen
  1017. To         Timothy Lang
  1018. Subject    Making TSR Programs
  1019.  
  1020.  
  1021.  
  1022.  TL> I know how to make normal programs in TP, but how can I make
  1023.  TL> TSR programs?  I have heard that I need to make memory
  1024.  TL> directives and I would need some type of HOT KEY mechanism
  1025.  TL> and so on...  What I want to do is take a flight manager
  1026.  TL> program I am working on and make it so that it loads and
  1027.  TL> then is activated at any time by hot key.  It does not have
  1028.  TL> to do anything when it is not active.
  1029.  
  1030.  
  1031. TSRs are both complex and tricky.  Professionals usually prefer to rely on
  1032. rock-solid, fully debugged commercial toolkits to do this.  Best I have seen
  1033. is "TSRs Made Easy" by Turbo Power.  This is a subset of their major toolbox,
  1034. Object Professional.  
  1035.  
  1036. Ross Wentworth's shareware TSR library (forgotten its name and I have not
  1037. got it) is another that seems to get good reviews.
  1038.  
  1039. If you particularly want to do this yourself then you have months of reading
  1040. books and experimentation ahead of you if it is to be done properly.  
  1041.  
  1042. TeeCee
  1043.  
  1044. --- TC-ED   v2.01  
  1045.  * Origin: The Pilbara's Pascal Centre (+61 91 732930) (3:690/644)
  1046.  * Tossed by SFToss v1.00b on 92/06/11  11:49:41
  1047.  
  1048. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  1049.  
  1050. Conference 4
  1051. Date       06-11-92 09:55:49
  1052. From       Trevor Carlsen
  1053. To         Scott Munger
  1054. Subject    XXX
  1055.  
  1056.  
  1057.  
  1058.  SM> The program needs a password to continue its execution.  I
  1059.  SM> want it to (instead of displaying the password) replace the
  1060.  SM> password with a x everytime someone types it in until they
  1061.  SM> press enter.  Just like your personal password when you log
  1062.  SM> on to a bbs.  Any help would be great.
  1063.  
  1064.  
  1065. Untested.
  1066.  
  1067. function Password(prompt: string): string;
  1068.   const
  1069.     BSpace= #8;
  1070.     CR    = #13;
  1071.     space = #32;
  1072.   var
  1073.     st   : string;
  1074.     len  : byte absolute st;
  1075.     done : boolean;
  1076.     col,
  1077.     row  : byte;
  1078.   begin
  1079.     done := false; len := 0;
  1080.     write(prompt);
  1081.     col := WhereX; row := WhereY;
  1082.     repeat
  1083.       st[succ(len)] := ReadKey;
  1084.       if st[succ(len)] = #0 then
  1085.         st[succ(len)] := ReadKey { discard extended keys }
  1086.       else case UpCase(st[succ(len)]) of
  1087.         BSpace : if len > 0 then begin
  1088.                    dec(len);
  1089.                    gotoXY(col+len,row);
  1090.                    write(space);
  1091.                    gotoXY(col+len,row);
  1092.                  end;
  1093.         CR      :done := true;
  1094.         'A'..'Z': begin
  1095.                     write('*'); { display * instead of character entered }
  1096.                     inc(len);
  1097.                   end;
  1098.         end; { case }
  1099.      until done;
  1100.      Password := st;
  1101.      writeln;
  1102.   end;  { Password }
  1103.  
  1104. I hope that there are no serious logic flaws or obvious errors there! :-)
  1105.  
  1106. TeeCee
  1107.         
  1108.                    
  1109.                    
  1110.  
  1111. --- TC-ED   v2.01  
  1112.  * Origin: The Pilbara's Pascal Centre (+61 91 732930) (3:690/644)
  1113.  * Tossed by SFToss v1.00b on 92/06/11  11:49:41
  1114.  
  1115. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  1116.  
  1117. Conference 4
  1118. Date       06-11-92 12:11:23
  1119. From       Trevor Carlsen
  1120. To         Dj Murdoch
  1121. Subject    Re: Tp 6 Exe Slow?
  1122.  
  1123.  
  1124.  
  1125.  TC> This was what I considered a good opportunity to (very 
  1126.  TC> roughly) compare the overhead of DV.  On my similar 
  1127.  TC> machine the above took 6.919 seconds.
  1128.  
  1129.  TC> It would seem that DV imposes a significant performance penalty.
  1130.  
  1131.  DM> Just redid the tests.  On a barebones machine, or one with
  1132.  DM> just QEMM loaded, I get about 16 or 17 seconds.  In a single
  1133.  DM> Desqview window I get the same.  Running two Desqview
  1134.  DM> windows, with one just sitting at the prompt, I get 25
  1135.  DM> seconds.  (That must have been what I had the first time.)
  1136.  DM> Running the same program simultaneously in the two windows,
  1137.  DM> I get 33 seconds.
  1138.  
  1139.  DM> So, it looks as though the Desqview overhead is pretty
  1140.  DM> minimal - better than I thought - provided you don't leave
  1141.  DM> windows sitting idle.
  1142.  
  1143.  DM> I don't know why you got 7 seconds though - what sort of
  1144.  DM> machine have you got?  Mine is a DTK, with supposedly a 256K
  1145.  DM> cache.  Norton's old SYSINFO gives it a 51.
  1146.  
  1147. Mine is an Australian built 486/33 with 128K cache running under DrDOS 6.0
  1148. and 4DOS.
  1149.  
  1150. However :-)  I cannot let you go on believing a part-truth!  I cheated!
  1151.  
  1152. I *did* use your program code with the only alteration being the adding of
  1153. a timer unit.  But I used very different compiler directives to you!  With
  1154. your compiler directives it took 15.213 seconds!  (You may recall that you
  1155. had at least R+ I+ S+)  It makes a huge difference when they are changed.
  1156.  The other possible difference is I run Eagle Performance Software's system unit.
  1157.  
  1158.  
  1159. Whilst the figure I quoted was truthful, the comparison was invalid.  It was
  1160. a "teaser" message. (I am not a vindictive person - I just get even! :-) 
  1161. We're 15 all now!)
  1162.  
  1163. TeeCee
  1164.  
  1165. --- TC-ED   v2.01  
  1166.  * Origin: The Pilbara's Pascal Centre (+61 91 732930) (3:690/644)
  1167.  * Tossed by SFToss v1.00b on 92/06/11  11:49:41
  1168.  
  1169. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  1170.  
  1171. Conference 4
  1172. Date       06-10-92 08:18:33
  1173. From       Dj Murdoch
  1174. To         Daniel Torrey
  1175. Subject    Re: C++ and Pascal
  1176.  
  1177.   DT> I'm trying to reuse some code in Pascal units.  I know 
  1178.  DT> that I have to declare the routines extern pascal, but I 
  1179.  DT> don't know how to link code that's stored in a Turbo 
  1180.  DT> Pascal 6.0 .TPU file into a C++ program.  Does anyone know 
  1181.  DT> how to do this?  I can't find any mention of it in either 
  1182.  DT> the Borland C++ or Turbo Pascal manuals.  Help!
  1183.  
  1184. I don't think it's possible.  TLINK doesn't understand .TPU files at all.
  1185.  You can, with a lot of work, link C++ .OBJ files into TP programs - take
  1186. a look in the manual for all the restrictions and details.
  1187.  
  1188. --- Msg V3.2
  1189.  * Origin: Murdoch's_Point  - -   (1:221/177.40)
  1190.  * Tossed by SFToss v1.00b on 92/06/11  15:56:00
  1191.  
  1192. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  1193.  
  1194. Conference 4
  1195. Date       06-09-92 21:12:02
  1196. From       Mark Ouellet
  1197. To         Rich Veraa
  1198. Subject    Re: your modem
  1199.  
  1200.  
  1201.     On 04 Jun 92, you, Rich Veraa, of 1:135/907.0 wrote...
  1202.  
  1203.  RV> A message from Trevor Carlsen to Rich Veraa was released into the
  1204.  RV> bitstream 30 May 92  09:48.
  1205.  RV> 
  1206.  TC>> I'd say there is a bug, rather than a
  1207.  TC>> problem with DV interaction problems.
  1208.  TC>> Most likely with pointers.  If you let
  1209.  TC>> me know where I can FREQ it from (and
  1210.  TC>> the filename), I'll pick it up and check it out for you.
  1211.  TC>> (I note that your number is unpublished)
  1212.  
  1213.  RV> Trevor, a friend of mine tried to send that with a 9600 v32, but could 
  1214.  
  1215.  RV> only connect with you at 2400.. We're not familiar with PEP -- is there 
  1216.  
  1217.  RV> some sort of secret to connect with it at 9600?
  1218.  
  1219. Rich,
  1220.         I'm afraid it isin't Trevor who is at fault, nor is
  1221. it his PEP modem. I ran up a 150 $Can LD bill trying to
  1222. connect with many ZONE 3 modems over a week-end. Tried my
  1223. trusty Courrier HST at first but when that didn't work I
  1224. tried borrowing my friend's HST DS which does V32, V32bis.
  1225.  
  1226.         I couldn't get a good connection then either. I
  1227. suspect the phone link I used was just too bad for the
  1228. connection. Maybe the trans-continent connection was the
  1229. problem. Satelite transmissions are sometimes hard because
  1230. of the delays involved in the reply.
  1231.  
  1232.         It is puzzleing though as I have had no problems
  1233. with Zone 2 or almost none, mostly a case of my HST finding
  1234. itself face-to-face with a V32/bis.
  1235.  
  1236.         I was about to try sending my mail to my Zone 3 gate
  1237. (which would be 1:3/0 since I'm in zone 1) but never got
  1238. around to calling him up to make sure it was ok.
  1239.  
  1240.         Sorry TC for the long OFF-TOPIC post, it has nothing
  1241. to do with Pascal but it is of interrest to others I think.
  1242.  
  1243.         Best regards,
  1244.         Mark Ouellet.
  1245.  
  1246.  
  1247.  
  1248. --- ME2
  1249.  * Origin: Governements, Proof of Peter's principle (Fidonet 1:240/1.4)
  1250.  * Tossed by SFToss v1.00b on 92/06/11  15:56:01
  1251.  
  1252. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  1253.  
  1254. Conference 4
  1255. Date       06-12-92 15:09:00
  1256. From       Norbert Igl
  1257. To         BRIAN PAPE
  1258. Subject    CLOCK PROBLEM
  1259.  
  1260.  
  1261.  
  1262. Hallo BRIAN,
  1263.  
  1264. am Dienstag, 09 Juni 1992 schrieb BRIAN PAPE an ALL:
  1265.  
  1266.  BP> program testclk;
  1267.  BP> uses crt;
  1268.  BP> var
  1269.  BP>   a,b,c,d:longint;
  1270.  BP>   timer:longint absolute $0:$469;
  1271.  
  1272.       --------------------------------
  1273.     That's the problem...
  1274.  
  1275.     Bios:Timertick is   Timer : Longint absolute $40:$6C; (* = 0:$46C *)
  1276.  
  1277.     you got a wrong val in your low-word, so .....
  1278.  
  1279.  
  1280.   Gruss aus Bonn, Norbert
  1281.  
  1282. --- GoldED 2.40
  1283.  * Origin:  May the source be with you... (2:241/5300.3)
  1284.  * Tossed by SFToss v1.00b on 92/06/13  20:57:32
  1285.